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Abstract 


This document creates a new IANA registry for tracking cost modes supported by the Application- 
Layer Traffic Optimization (ALTO) Protocol. Also, this document relaxes a constraint that was 
imposed by the ALTO specification on allowed cost mode values. 


This document updates RFC 7285. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9274. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


The cost mode attribute indicates how costs should be interpreted when communicated as 
described in "Application-Layer Traffic Optimization (ALTO) Protocol" [RFC7285], which includes a 
provision for only two modes: 


"numerical": Indicates that numerical operations can be performed (e.g., normalization) on the 
returned costs (Section 6.1.2.1 of [RFC7285]). 


"ordinal": Indicates that the cost values in a cost map represent ranking (relative to all other 
values in a cost map), not actual costs (Section 6.1.2.2 of [RFC7285]). 
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Additional cost modes are required for specific ALTO deployment cases (e.g., [ALTO-PV]). In order 
to allow for such use cases, this document relaxes the constraint imposed by the base ALTO 
specification on allowed cost modes (Section 3) and creates a new ALTO registry to track new 
cost modes (Section 5). 


The mechanisms defined in [RFC7285] are used to advertise the support of new cost modes for 
specific cost metrics. Refer to Section 4 for more details. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


This document makes use of the terms defined in [RFC7285]. 


3. Updates to RFC 7285 


3.1. Updates to Section 6.1.2 of RFC 7285 
This document updates Section 6.1.2 of [RFC7285] as follows: 


OLD: 


The cost mode attribute indicates how costs should be interpreted. Specifically, the cost mode 
attribute indicates whether returned costs should be interpreted as numerical values or 
ordinal rankings. 


It is important to communicate such information to ALTO clients, as certain operations may 
not be valid on certain costs returned by an ALTO server. For example, it is possible for an 
ALTO server to return a set of IP addresses with costs indicating a ranking of the IP addresses. 
Arithmetic operations that would make sense for numerical values, do not make sense for 
ordinal rankings. ALTO clients may handle such costs differently. 


Cost modes are indicated in protocol messages as strings. 
NEW: 


The cost mode attribute indicates how costs should be interpreted. Two cost modes 
(numerical values and ordinal rankings) are defined, but additional cost modes can be 
defined in the future. 


It is important to communicate such information to ALTO clients, as certain operations may 
not be valid on certain costs returned by an ALTO server. For example, it is possible for an 
ALTO server to return a set of IP addresses with costs indicating a ranking of the IP addresses. 
Arithmetic operations that would make sense for numerical values, do not make sense for 
ordinal rankings. ALTO clients may handle such costs differently. 
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Cost modes are indicated in protocol messages as strings. 


For any future documents that defines a new cost mode, indicating whether that new cost 
mode applies to all or a subset of cost metrics is strongly recommended. This 
recommendation is meant to prevent nondeterministic behaviors that may result in 
presenting a cost mode with a specific metric, while such an association does not make sense 
or can't be unambiguously interpreted by ALTO implementations. 


If the definition of a cost mode does not indicate whether that cost mode applies to a subset 
of cost metrics, ALTO implementations MUST be prepared to accept that cost mode for any 
cost metric. 


3.2. Updates to Section 10.5 of RFC 7285 
This document updates Section 10.5 of [RFC7285] as follows: 


OLD: 


Acost mode is encoded as a string. The string MUST have a value of either "numerical" or 
"ordinal". 


NEW: 


A cost mode is encoded as a string. The string MUST be no more than 32 characters, and it 
MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, 
U+0041-U+005A, and U+0061-U+007A), the hyphen-minus ('-', U+002D), the colon (':', U+003A), or 
the low line (‘_', Ut005F). Cost modes reserved for Private Use are prefixed with "priv:" 
(Section 5). Otherwise, the cost mode MUST have a value that is listed in the registry created in 
Section 5 of [RFC9274]. 


4. Backward Compatibility Considerations 


ALTO servers that support new cost modes for specific cost metrics will use the mechanism 
specified in Section 9.2 of [RFC7285] to advertise their capabilities. ALTO clients (including legacy) 
will use that information to specify cost constraints in their requests (e.g., indicate a cost metric 
and a cost mode). An example of sucha behavior is depicted in Section 9.2.3 of [RFC7285]. 


If an ALTO client includes a cost mode that is not supported by an ALTO server, the server 
indicates such an error with the error code E_INVALID_FIELD_VALUE as per Section 8.5.2 of 
[RFC7285]. In practice, legacy ALTO servers will reply with the error code 
E_INVALID_FIELD_VALUE to requests that include a cost type other than "numerical" or "ordinal" 
for the "routingcost" cost metric. 


The encoding constraints in Section 3.2 do not introduce any interoperability issue given that 
currently implemented cost modes adhere to these constrains (mainly, those in [RFC7285] and 
LALTO-PV)). 
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5. IANA Considerations 


IANA has created the new "ALTO Cost Modes" subregistry within the "Application-Layer Traffic 
Optimization (ALTO) Protocol" registry available at [ALTO]. 


The assignment policy for this subregistry is "IETF Review" (Section 4.8 of [RFC8126]). 
Requests to register a new ALTO cost mode must include the following information: 


Identifier: The name ofthe ALTO cost mode. Refer to Section 3.2 for more details on allowed 
encoding. 


Description: Ashort description of the requested ALTO cost mode. 
Intended Semantics: Areference to where the semantic of the requested cost mode is defined. 


Reference: Areference to the document that registers the requested cost mode. 
Cost modes prefixed with "priv:" are reserved for Private Use (Section 4.1 of [RFC8126]). IANA has 
added the following note to the new subregistry: 


Identifiers prefixed with "priv:" are reserved for Private Use (see RFC 9274, Section 5). 


The subregistry is initially populated with the following values: 


Identifier Description Intended Reference 
Semantics 
numerical Indicates that numerical operations can be Section 6.1.2.1 of RFC 9274 
performed on the returned costs [RFC7285] 
ordinal Indicates that the cost values in a cost map Section 6.1.2.2 of RFC 9274 
represent ranking [RFC7285] 


Table 1: ALTO Cost Modes 
6. Security Considerations 
This document does not introduce new concerns other than those already discussed in Section 15 


of [RFC7285]. 
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